In modern and future communication networks including fixed and mobile telecommunication networks (such as for example Internet Protocol-based networks, Global System for Mobile Communication (GSM), General Packet Radio Service (CPRS), Universal Mobile Telecommunication System (UMTS), Long-Term Evolution (LTE) or the like) security and trustworthiness issues play an increasingly important role. Therefore, AAA (authentication, authorization and accounting) infrastructure is being usually deployed in or on top of such communication networks.
According to current techniques in the AAA field, such AAA infrastructure is organized and managed based on so-called realms (sometimes also referred to as domains) representing administrative entities within an overall AAA system of a single operator or provider. One known approach resides in that an overall AAA system of a single operator or provider comprises a single realm. That is, the entire AAA infrastructure in such an overall AAA system is organized and managed in a single overall realm (i.e. domain).
An organization or management of AAA infrastructure within a single realm may, however, have drawbacks in view of server failures.
In a large realm (such as e.g. “company.com”), which is operated e.g. by a large mobile operator, there may be regional sites including one or more AAA servers serving one or more AAA clients residing in the topological or geographical area covered by the respective regional site. Such regional sites do not represent administrative entities, but may be regarded as autonomous in that they share the same “operator-global” subscription data which is completely or at least partly replicated in respective AAA servers (and related databases etc.) of the individual regional sites. Especially in a large network (i.e. a large realm), for example in a nation-wide or even continent-wide deployment (such as that of an American or Chinese operator) of AAA infrastructure, regional sites with AAA servers and AAA clients may be topologically and geographically far away from each other. In case of a server failure in a regional site, the clients are to be delegated to a remote regional site as a backup operation.
While there are known certain fallback mechanisms in the context of AAA infrastructure failures, such as e.g. Diameter fallback mechanisms when Diameter is used as an AAA protocol, the known fallback mechanisms do not perform well or even do not work properly in a single-realm AAA system. That is, in case of a failure of an AAA server in a regional site within a single-realm AAA system, the known fallback mechanisms are not capable of ensuring an appropriate delegation of clients of the failed server to a backup server as well as an appropriate (i.e. instant and reliable) traffic handling in this regard. While this drawback exists in any single-realm AAA system, it is particularly adverse in large single-realm AAA systems (especially those in which regional sites are interconnected over an intra-operator network) because the known fallback mechanisms do not scale well and are error prone. In this regard, continent wide intra-operator networks could be mentioned as a non-limiting example for large single-realm AAA systems in question.
On the other hand, there are no standardized fallback mechanisms in other authentication environments, such as e.g. when RADIUS is used as an AAA protocol.
Accordingly, there does not exist any feasible solution for an intra-realm AAA fallback mechanism, in particular a fallback mechanism in case of a server failure within a (large) single-realm AAA infrastructure.